DevOps の第 1 の道 : フローの原則
顧客にすばやく価値を届けるために、開発から運用への作業の流れを早くスムースにする
作業を可視化し、バッチサイズを縮小し、作業のインターバルを短縮し、品質を組み込んで下流に不良品が流れないようにする やるべきこと
作業の可視化
IT のバリューストリームと生産のバリューストリームの大きな違いは、IT のバリューストリームは目に見えないこと 受け渡しの回数を制限する
DevOps 改革の中では、一般的に制約条件は次のように変わっていく 1. 環境の作成
2. コードのデプロイ
3. テストの準備と実行
4. 過度に密結合なアーキテクチャ
バリューストリームからムダと苦痛を取り除く
部分的に完成した仕事、余分な処理、余分な機能、タスク切り替え、待機、動作、不良、非標準的な作業や手作業、超人的な作業
3 部 第 1 の道 : フロー改善の技術的実践
9 章 デプロイパイプラインの基礎の構築
本番環境を手作業で変更することを禁止して、コードの変更により本番環境に反映するように
開発の完成の定義を、「本番環境に近い環境で予定通りに動作することを確認する」 こととする
10 章 高速で信頼性の高い自動テストの実現
一般に、自動テストは高速なものから次のように分類される 11 章 継続的インテグレーションの実現と実践
12 章 自動化とローリスクリリースの実現
デプロイプロセスの自働化 : 既存のプロセスをドキュメント化し、それを単純化し、自動化する
これらを独立させることで、開発と運用は速くて頻繁なデプロイの責任、製品オーナーはリリースをビジネスとして成功させる責任をそれぞれ負うことができる
リリースのパターンは 2 つ
環境ベースのリリース : トラフィックを環境で切り替えてリリース
アプリケーションベースのリリース : 小さな設定変更で選択的にアプリケーションの機能をリリース
13 章 ローリスクリリースのアーキテクチャ
アーキテクチャをどう移行するか?
eBay では、小さなパイロットプロジェクトで問題理解を自身に示して、それから書き換えに踏み込む 企業が製品ライフサイクルの初期にいるときはモノリシックなアーキテクチャが最良である場合も多い